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(54) Mechanism lor determining restrictions to impose on an implementation of a service 



(57) A mechanism for determining restrictions to im- 
pose on an implementation of a service is disclosed. 
When an application desires an implementation for a 
particular service, the application makes a request to a 
framework. The framework receives the request and, in 
response, determines what restrictions, if any, need to 
be imposed on the requested implementation. The re- 
strictions are determined by determining whether any 
permissions have been granted to the application re- 
questing the implementation, and if so, processing the 
permissions to derive a set of zero or more restrictions 
to impose on the implementation. The permissions are 
processed such that the set of restrictions is least re- 



strictive. Once the restrictions are determined, the 
framework dynamically constructs the requested imple- 
mentation. The requested implementation is construct- 
ed such that it incorporates a general implementation of 
the service, the restrictions, and enforcement logic for 
enforcing the restrictions on the general implementa- 
tion. Once the requested implementation is constructed, 
it is provided to the application. Thereafter the applica- 
tion invokes the requested implementation directly for 
services. Since the requested implementation incorpo- 
rates the restrictions and enforcement logic for enforc- 
ing the restrictions, it will guarantee that the restrictions 
are enforced. 
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Description 

Background 

[0001] This invention relates generally to computer 
systems, and more particularly to a mechanism for de- 
termining the restrictions to impose on an implementa- 
tion of a service requested by an application. 
[0002] For a number of years, the U. S. Department 
of Commerce has regulated, and at times, prohibited the 
exportation of computer programs or applications which 
implement data encryption algorithms. Currently, com- 
puter programs cannot, as a general rule, be exported 
if they implement encryption algorithms having crypto- 
graphic key sizes exceeding a certain number of bits 
(the specific allowable key size is algorithm-specific). 
There are certain exceptions to this rule. One exception 
is that if an exemption mechanism is implemented, the 
key size, and hence the cryptographic strength of the 
program, may in some cases be increased. Examples 
of exemption mechanisms include key escrow, key re- 
covery, and key weakening. Also, certain types of pro- 
grams are allowed to use larger key sizes than others. 
For example, current regulations allow health care and 
financial services applications to use larger key sizes 
because of the need for increased security (to protect 
highly sensitive data) in these types of applications. 
While some applications may enjoy greater latitude than 
others, all encryption applications are subject to export 
regulations. 

[0003] These regulations apply not only to programs 
which directly implement encryption algorithms, but also 
to programs which interface with programs that directly 
implement encryption algorithms. These programs in- 
clude "framework" programs which provide infrastruc- 
ture for facilitating interaction between various pro- 
grams. The framework itself may not implement any en- 
cryption algorithm, but it may allow one or more pro- 
grams which do implement encryption algorithms to in- 
terface with or "plug in" to the framework. An example 
of such a framework is the Java Cryptography Extension 
to the Java Platform manufactured by Sun Microsys- 
tems, Inc. of Palo Alto, California. If a framework allows 
an encryption mechanism to be "plugged in" to the 
framework, the framework itself will be subject to export 
regulations. This means that in order to be exportable, 
the framework needs to ensure that all export regula- 
tions are adhered to regardless of the encryption imple- 
mentation that is plugged in to the framework. In order 
to do this, the framework needs to have some mecha- 
nism for enforcing the necessary restrictions on the en- 
cryption implementations. 

[0004] These regulations apply not only to programs 
which directly implement encryption algorithms, but also 
to programs which interface with programs that directly 
implement encryption algorithms. These programs in- 
clude "framework" programs which provide infrastruc- 
ture for facilitating interaction between various pro- 
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grams. The framework itself may not implement any en- 
cryption algorithm, but it may allow one or more pro- 
grams which do implement encryption algorithms to in- 
terface with or "plug in" to the framework. An example 

5 of such a framework is the Java Cryptography Extension 
to the Java Platform manufactured by Sun Microsys- 
tems, Inc. of Mountain View, California. If a framework 
allows an encryption mechanism to be "plugged in" to 
the framework, the framework itself will be subject to ex- 

10 port regulations. This means that in order to be export- 
able, the framework needs to ensure that all export reg- 
ulations are adhered to regardless of the encryption im- 
plementation that is plugged in to the framework. In or- 
der to do this, the framework needs to have some mech- 

15 anism for enforcing the necessary restrictions on the en- 
cryption implementations. 

Summary of the Invention 

20 [0005] Particular and preferred aspects of the inven- 
tion are set out in the accompanying independent and 
dependent claims. Features of the dependent claims 
may be combined with those of the independent claims 
as appropriate and in combinations other than those ex- 

25 plicitly set out in the claims. 

[0006] In accordance with the present invention, there 
is provided a mechanism for dynamically constructing 
customized implementations to enforce restrictions on 
services. For purposes of the present invention . a serv- 

30 ice is defined broadly to encompass any functionality re- 
quested by and provided to an application, including but 
not limited to encryption/decryption functionality. In one 
embodiment, the invention is implemented in a system 
comprising an application, a general implementation of 

35 a particular service, and a framework. 

[0007] The framework receives from the application a 
request for an implementation of a particular service, 
such as an implementation of a particular encryption al- 
gorithm. In response, the framework determines what 

^0 restrictions, if any, need to be imposed on the requested 
implementation. In one embodiment, the framework de- 
termines the restrictions by determining whether any 
permissions have been granted to the application, and 
if so. processing the permissions to derive the set of re- 

45 strictions to impose on the implementation. In one em- 
bodiment, the permissions are processed such that the 
set of restrictions derived is least restrictive. 
[0008] Once the restrictions are determined, the 
framework dynamically constructs the requested imple- 

50 mentation. In one embodiment, the requested imple- 
mentation is constructed such that it incorporates the 
general implementation of the service, the restrictions, 
and enforcement logic for enforcing the restrictions on 
the general implementation. Since the requested imple- 

55 mentation is constructed specifically for the application, 
it is customized for the application. Thus, the implemen- 
tation is referred to as the customized implementation. 
[0009] Once the customized implementation is dy- 
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namicalty constructed, the framework provides the cus- 
tomized implementation to the application. Thereafter, 
the application invokes the customized implementation 
directly for services. Since the customized implementa- 
tion incorporates the restrictions and enforcement logic 
for enforcing the restrictions, it is not necessary for the 
application to further interact with the framework. The 
customized implementation itself will provide the serv- 
ices, and will guarantee that the restrictions are en- 
forced. By dynamically constructing customized imple- 
mentations in this manner, the framework ensures that 
the necessary restrictions are enforced on the services 
provided to the application. 

Brief Description of the Drawings 

[0010] Exemplary embodiments of the invention are 
described hereinafter, by way of example only, with ref- 
erence to the accompanying drawings, in which: 
[0011] Fig. 1 is a block diagram of an overall system 
in which one embodiment of the present invention may 
be implemented. 

[0012] Fig. 2 is a flow diagram illustrating the general 
operation of the overall system of Fig. 1 . 
[0013] Fig. 3 is a detailed block diagram of one pos- 
sible embodiment of the present invention. 
[0014] Fig. 4 is a flow diagram illustrating the opera- 
tion of the embodiment of Fig. 3. 
[001 5] Fig. 5 depicts a sample set of limitations includ- 
ing a default set and an exempt set. 
[0016] Fig. 6 is a flow diagram illustrating the opera- 
tion of one embodiment of the GetCrypto Permission 
method of the JCESecurityManager object class. 
[0017] Fig. 7 depicts an overview of the process of 
merging multiple sets of laws into a single set of limita- 
tions in accordance with one embodiment of the present 
invention. 

[0018] Fig. 8 is a flow diagram illustrating the manner 
in which multiple sets of laws are merged into a single 
set of limitations in accordance with one embodiment of 
the present invention. 

[0019] Fig. 9 is a flow diagram illustrating the manner 
in which an untrusted digital signature verification mech- 
anism may be tested for legitimacy in accordance with 
one embodiment of the present invention. 
[0020] Fig. 10 is a flow diagram illustrating the manner 
in which any untrusted mechanism may be tested for 
legitimacy in accordance with one embodiment of the 
present invention. 

[0021] Fig. 11 is a hardware block diagram of a com- 
puter system in which the present invention may be im- 
plemented. 

Detailed Description of Embodiment(s) 

[0022] With reference to Fig. 1 , there is shown a block 
diagram of a system 100 in which one embodiment of 
the present invention may be implemented, the system 



100 comprising one or more applications 104, one or 
more general implementations 106, a set of specified 
limitations 10B, and a framework 102 for facilitating in- 
teraction between the various components. The appli- 

5 cations 104, which may be any type of application or 
program, including but not limited to Java applets, Java 
applications, and native compiled applications, request 
and receive implementations of services from the frame- 
work 102. For purposes of the present invention, the 

10 term "service" is defined broadly to encompass any 
functionality requested by and provided to an applica- 
tion, including but not limited to encryption/decryption 
functionality. 

[0023] When an application 104 requests an imple- 

'5 mentation from the framework 1 02, the application 1 04 
specifies the type of service for which it wishes an im- 
plementation. For example, the application 104 may re- 
quest an implementation for the "Blowfish" encryption 
algorithm. In response, the framework 102 provides an 

20 implementation of the requested service to the applica- 
tion 1 04 which is customized for the application 1 04 
making the request. The customized implementation 
provided by the framework 1 02 may contain restrictions 
on the services that it can provide. As will be discussed 

25 later, these restrictions are determined based upon the 
set of specified limitations 1 08 and the permissions 110, 
if any, granted to the application 1 04 making the request. 
[0024] The general implementations 106 represent 
the implementations for services that can be "plugged 

30 in" to or interfaced with the framework 102. Each gen- 
eral implementation 106 implements a particular type of 
service. For example, one general implementation may 
implement the "Blowfish" encryption algorithm, while 
another may implement the DES encryption algorithm. 

35 Each general implementation 106 is unrestricted. That 
is, regardless of the presence of limitations 108 or per- 
missions 110. the general implementations 106 them- 
selves are not hampered by restrictions. In the case 
where the general implementations 106 are implemen- 

40 tations of encryption algorithms, this means that the en- 
cryption algorithms may be set to full strength. As will 
be explained below, it is the framework 1 02, not the gen- 
eral implementations 106, that ensures that the proper 
restrictions are enforced on the services provided to the 

45 applications 104. 

[0025] In system 1 00, the framework 1 02 is the com- 
ponent responsible for coordinating the overall opera- 
tion of the system 100. A flowchart illustrating the gen- 
eral operation of the framework 102 is shown in Fig. 2. 

50 As shown in Fig. 2, the framework 102 operates by re- 
ceiving ( 202 ) a request from an application 1 04 for an 
implementation of a particular type of service (e.g. an 
implementation for the "Blowfish" encryption algorithm). 
In response, the framework 102 determines ( 204 ) what 

55 restrictions, if any, need to be imposed on the requested 
implementation. In one embodiment, the framework 1 02 
determines the restrictions by reconciling the specified 
limitations 108 with the permissions 110, if any, granted 
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to the application 104 making the request. In doing so, 
the framework 1 02 attempts, in one embodiment, to im- 
pose the lowest level of restriction possible. Put another 
way, the framework 1 02 tries to be as permissive as pos- 
sible in light of the permissions 110 and the limitations 
108. 

[0026] Once the restrictions are determined, the 
framework 102 dynamically constructs ( 206 ) the re- 
quested implementation. In one embodiment, the re- 
quested implementation is constructed by finding an as- 
sociated general implementation 1 06 which implements 
the type of service requested (e.g. a general implemen- 
tation 106 which implements the "Blowfish" encryption 
algorithm). Once found, the associated general imple- 
mentation 106 is incorporated into the requested imple- 
mentation, along with the restrictions determined previ- 
ously In addition, a set of enforcement logic is also in- 
corporated into the requested implementation. This en- 
forcement logic ensures that the restrictions are en- 
forced on the associated general implementation 1 06. 
Thus, even though the associated general implementa- 
tion 1 06 itself may not have any restrictions, the enforce- 
ment logic causes the proper restrictions to be enforced 
on the associated general implementation 1 06. With the 
associated general implementation, the restrictions, 
and the enforcement logic incorporatedtherein, the con- 
struction of the requested implementation is complete. 
Since the requested implementation is constructed spe- 
cifically for the requesting application 104, and hence, 
may incorporate restrictions specific to the requesting 
application, the requested implementation may be 
viewed as a customized implementation which is cus- 
tomized for the requesting application 104. 
[0027] Once the customized implementation is con- 
structed, it is provided ( 208 ) to the requesting applica- 
tion 1 04. Thereafter, the application 1 04 may directly re- 
quest services from the customized implementation. 
Since the customized implementation incorporates the 
restrictions and enforcement logic for enforcing the re- 
strictions, it is not necessary for the application 104 to 
further interact with the framework 1 02. The customized 
implementation itself will provide the services, and will 
guarantee that the restrictions are enforced on the serv- 
ices. By dynamically constructing customized imple- 
mentations in this manner, the framework 1 02 ensures 
that the necessary restrictions are enforced on the serv- 
ices provided to the application 104. 
[0028] The above discussion provides a general over- 
view of the present invention. With reference to Fig. 3, 
one possible embodiment of the invention will now be 
described in detail. In the following discussion, the in- 
vention will be described with reference to an object ori- 
ented implementation in which the services requested 
and provided are cryptographic services. It should be 
noted that this is for illustrative purposes only. The in- 
vention is not so limited. Rather, the invention may be 
applied generally to any type of programming environ- 
ment and any type of service on which restrictions need 



to be enforced. 

[0029] Fig. 3 shows the framework 1 02 in greater de- 
tail. As shown, the framework 102 comprises an appli- 
cation programming interface (API) 302, a service pro- 
5 vider interface (SPI) 304, and a core 320. The API 302 
represents the resources that the applications 104 can 
call or invoke directly In one embodiment, the API 302 
comprises a Cipher object class 306 and an Exemption- 
Mechanism object class 308. Among other methods, the 
io Cipher object class 306 comprises a Getlnstance meth- 
od and an Init method. Getlnstance is the method that 
is called by an application 104 when the application re- 
quests an implementation of a service. In response to 
this method call, an instance of the Cipher object class 
'5 306 is constructed and returned to the calling application 
1 04. The Cipher instance that is returned is customized 
for the calling application, and contains restrictions and 
enforcement logic for enforcing the restrictions on the 
services that the Cipher instance can provide. Once re- 
turned, the methods of the Cipher instance are invoked 
directly by the calling application 1 04. One of the meth- 
ods that needs to be invoked by the calling application 
1 04 is the init method. This method initializes the Cipher 
instance and prepares it for operation. In addition, the 
Init method acts as the enforcement logic for enforcing 
the restrictions on the Cipher instance. The Getlnstance 
and Init methods will be described in greater detail in a 
later section. 

[0030] As mentioned previously, it is sometimes per- 
missible to implement encryption algorithms with great- 
er cryptographic strength (e.g. with larger key sizes) if 
one or more exemption mechanisms (such as key es- 
crow, key recovery, or key weakening) are implemented. 
If an exemption mechanism is implemented, then the 
ExemptionMechanism object class 308 comes into play. 
This class provides several methods that can be called. 
These methods may be called to invoke the functionality 
of a particular exemption mechanism (e.g. to generate 
key recovery blocks where the exemption mechanism 
is key recovery), and to determine whether the neces- 
sary operations have been performed (e.g. whether the 
key recovery blocks have been generated). More will be 
said about the object classes 306, 308 of the API 302 
in a later section. 

[0031] The SPI 304 provides the interface needed by 
service providers to plug their service implementations 
into the framework 102. In one embodiment, the SPI 304 
comprises a corresponding SPI 304 object class for 
each API 302 object class. That is, for the Cipher object 
class 306 in the API 302, there is a corresponding Ci- 
pherSpi object class 310 in the SPI 304, and for the Ex- 
emptionMechanism object class 308 in the API 302, 
there is a corresponding ExemptionMechanismSpi ob- 
ject class 312 in the SPI 304. This one to one corre- 
spondence makes it simple to map the methods in the 
API classes 306, 308 to the methods in the SPI classes 
310, 312. The significance of this will be made clear in 
a later section. The SPI object classes 310, 312 are ab- 
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stract object classes, meaning that while they set forth 
methods which are to be implemented by the classes, 
they do not themselves provide any implementations for 
these methods. It is up to the service providers to pro- 
vide the implementations. To provide an implementation 5 
106 for a service, a service provider subclasses one of 
the object classes of the SPI 304, and provides, in the 
subclass, implementations for all of the defined methods 
of the SPI class. Thus, the general implementations 106 
shown in Fig. 3 are subclasses of the object classes 310, io 
312 of the SPI 304. Each general implementation 106 
may implement a different type of service (e.g. one may 
implement the Blowfish encryption algorithm while an- 
other implements the DES encryption algorithm while 
another implements the key recovery exemption mech- '5 
anism), and each general implementation 106 may be 
implemented without any restrictions. This means that 
the general implementations 106 may be full strength 
implementations (e.g. may use unlimited encryption key 
sizes). 20 

[0032] The core 320 of the framework 1 02 comprises 
a JCESecurity object class 314 and a JCESecurityMan- 
ager object class 31 6, In one embodiment, these object 
classes 314, 316 are package private and cannot be ac- 
cessed directly by the applications 104. As shown, the 25 
JCESecurity class comprises a Getlmpl method, and 
the JCESecurityManager class comprises a GetCryp- 
toPermission method. These methods are invoked as a 
result of the invocation of the Getlnstance method of the 
Cipher class 306, and together they perform much of 30 
the work needed to dynamically construct a customized 
implementation. The functions performed by these 
methods are best understood in the context of the entire 
system. Thus, with reference to the flow diagram of Fig. 
4, the overall operation of the system will now be de- 35 
scribed to facilitate a complete understanding of the in- 
vention. 

[0033] When an application 104 desires an imple- 
mentation of a particular encryption service, it makes a 
request for an implementation by calling the Ge- *o 
tlnstance method of the Cipher object class 306. Spec- 
ified in this call is the type of service for which the appli- 
cation is requesting an implementation. In one embod- 
iment, this takes the form of an encryption algorithm 
name, such as Blowfish. The Cipher class 306 receives ^ 
(404) this request and invokes the functionality of the 
Getlnstance method. In response, the Getlnstance 
method calls the Getlmpl method of the JCESecurity 
class 31 4. 

[0034] The Getlmpl method performs several major so 
functions. First, it determines ( 408 ) whether a general 
implementation 106 is available which implements the 
requested type of service. For example, it determines 
whether any of the general implementations 106 imple- 
ments the Blowfish encryption algorithm. If no such gen- 55 
eral implementation 106 is found, then it returns ( 412) 
an error message to the Getlnstance method, which in 
turn, returns an error message to the calling application 
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104. However, if a general implementation 106 is found 
which implements the requested service, then the 
Getlmpl method proceeds to determine ( 416 ) whether 
that general implementation is authentic. The manner is 
which this authentication is carried out will be described 
in greater detail in a later section, but suffice it to say at 
this point that the authentication is carried out using a 
digital signature verification mechanism. 
[0035] If the Getlmpl method determines that the gen- 
eral implementation is not authentic, then it determines 
( 420 ) whether there is another general implementation 
1 06 which implements the requested service. If not, then 
the Getlmpl method returns ( 424 ) an error message to 
the Getlnstance method, which in turn, returns an error 
message to the calling application 1 04. If there is anoth- 
er general implementation which implements the re- 
quested service, the Getlmpl method loops back to 
( 416 ) to determine whether the new general implemen- 
tation is authentic. This process continues until either 
an authentic implementation is found or it is determined 
that there are no authentic general implementations 1 06 
which implement the requested service. 
[0036] If an authentic general implementation 1 06 for 
the requested service is found (this implementation will 
be referred to as the associated implementation), then 
the Getlmpl method instantiates ( 428 ) the associated 
implementation to give rise to an implementation in- 
stance (i.e. a CipherSpi instance). Thereafter, the 
Getlmpl method determines ( 432 ) whether any restric- 
tions need to be imposed on the implementation in- 
stance. In one embodiment, this determination is made 
by determining whether the framework 1 02 has been set 
for domestic or global operation. If it has been set for 
domestic use only, then export regulations do not apply; 
thus, no restrictions need to be imposed. On the other 
hand, if the framework 102 is set for global operation, 
then possible restrictions are to be taken into account. 
[0037] To determine (436 ) the restrictions to be im- 
posed on the implementation instance, the Getlmpl 
method calls the GetCrypto Permission method of the 
JCESecurityManager class 316. The main function of 
the GetCryptoPermission method is to reconcile the 
specified limitations 1 08 with the permissions 1 1 0, if any, 
granted to the calling application 104 to derive a set of 
restrictions. This set of restrictions is returned by the 
GetCryptoPermission method to the Getlmpl method, 
and in one embodiment, includes the name of the re- 
quested encryption algorithm, the name of the exemp- 
tion mechanism (if any) that is to be enforced, and some 
encryption parameters, such as the maximum key size 
that can be used, and the maximum number of rounds 
of encryption that can be performed (this is required by 
some algorithms such as RC5). Upon receiving the re- 
strictions, the Getlmpl method determines (440 ) wheth- 
er an exemption mechanism is specified in the restric- 
tions. If not, then the Getlmpl method proceeds to block 
( 448 ). 

[0038] However, if an exemption mechanism is spec- 
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ified, then the Getlmpl method proceeds to give rise to 
an instance of the specified exemption mechanism. In 
one embodiment, this is achieved by calling the Ge- 
tlnstance method of the ExemptionMechanism class 
308, passing along the name of the exemption mecha- 5 
nism. In response to this call, the Getlnstance method 
of the ExemptionMechanism class 308 calls the Getlmpl 
method of the JCESecurity class 314 (notice that this is 
a second call to the Getlmpl method). In response, the 
Getlmpl method searches for a valid general implemen- 10 
tation 1 06 which implements the specified exemption 
mechanism, and instantiates ( 444 ) the general imple- 
mentation 106 to give rise to an ExemptionMechanism- 
Spi instance. Thereafter, the Getlmpl method returns 
(this is a return from the second call to the Getlmpl meth- '5 
od) the ExemptionMechanismSpi instance to the Ge- 
tlnstance method of the ExemptionMechanism class 
308. 

[0039] The Getlnstance method of the Exemption- 
Mechanism class 308 then invokes the constructor of 20 
the ExemptionMechanism class 308, passing to the 
constructor the ExemptionMechanismSpi instance re- 
turned from the Getlmpl method. When invoked, the 
constructor instantiates the ExemptionMechanism 
class 308, giving rise to an ExemptionMechanism in- 25 
stance. Then, the constructor encapsulates the Exemp- 
tionMechanismSpi instance within the ExemptionMech- 
anism instance. In doing so, the constructor maps the 
methods of the ExemptionMechanism instance to cor- 
responding methods of the ExemptionMechanismSpi 30 
instance. In one embodiment, the Init method of the Ex- 
emptionMechanism instance is mapped to the Enginel- 
nit method of the ExemptionMechanismSpi instance, 
and the GenExemptionBlob method is mapped to the 
EngineGenExemptionBlob method. This mapping ena- 35 
bles calls to the methods of the ExemptionMechanism 
instance to be routed to the proper methods of the Ex- 
emptionMechanismSpi instance. Once the Exemption- 
MechanismSpi instance is encapsulated within the Ex- 
emptionMechanism instance, the instantiation of the Ex- *o 
emptionMechanism instance is complete. 
[0040] Thereafter, the Getlmpl method returns (this is 
a return from the first call to the Getlmpl method) to the 
Getlnstance method of the Cipher class 306, providing 
to the Getlnstance method the implementation instance, 45 
the set of restrictions, and the ExemptionMechanism in- 
stance (if any). The Getlnstance method of the Cipher 
class 306 then invokes the constructor of the Cipher 
class 306, passing to the constructor the implementa- 
tion instance, the set of restrictions, and the Exemption- so 
Mechanism instance (if any) received from the Getlmpl 
method. In response, the constructor instantiates ( 448 ) 
the Cipher class 306 to give rise to a Cipher instance. 
The constructor then encapsulates (452 ) the implemen- 
tation instance, the set of restrictions, and the Exemp- 55 
tionMechanism instance (if any) within the Cipher in- 
stance. In effect, the Cipher instance acts as a "wrapper" 
object. In encapsulating the implementation instance 



within the Cipher instance, the constructor maps the 
methods of the Cipher instance to corresponding meth- 
ods of the implementation instance. In one embodiment, 
the Init method of the Cipher instance is mapped to the 
Enginelnit method of the implementation instance, the 
Update method is mapped to the EngineLlpdate meth- 
od, and the Do Final method is mapped to the EngineD- 
oFinal method. This mapping enables calls to the meth- 
ods of the Cipher instance to be routed to the proper 
methods of the implementation instance. This is as it 
should be since the implementations for these methods 
are provided by the implementation instance. Once the 
encapsulation process is complete, the constructor re- 
turns to the Getlnstance method of the Cipher class 306. 
In turn, the Getlnstance method returns to the calling 
application 104, providing (456 ) to the application 104 
the newly constructed Cipher instance. Thereafter, the 
calling application 104 may invoke the methods of the 
Cipher instance directly. 

[0041] In one embodiment, one of the first methods 
that the calling application 1 04 needs to invoke on the 
Cipher instance is the Init method. This methods serves 
to initialize the Cipher instance to prepare it for normal 
operation. When calling this method, the calling appli- 
cation 104 provides a set of initialization parameters. In 
one embodiment, these parameters include the encryp- 
tion key to be used for encryption, and optionally other 
encryption parameters specifying algorithm-specific 
properties, such as the number of rounds of encryption 
(if needed by the particular encryption algorithm). 
[0042] When called, the Init method compares the in- 
itialization parameters passed in by the calling applica- 
tion 104 against the restrictions encapsulated within the 
Cipher instance. If the initialization parameters are at or 
below the levels of the restrictions, then the Init method 
passes the initialization parameters on to the Enginelnit 
method of the implementation instance to enable the im- 
plementation instance to initialize. Once the implemen- 
tation instance is initialized, the Cipher instance is ready 
for operation; thus, the Update and DoFinal methods of 
the Cipher instance may be invoked by the calling ap- 
plication 104 to perform encryption/decryption opera- 
tions. However, if the Init method determines that the 
initialization parameters passed in by the calling appli- 
cation 104 exceed the levels of the encapsulated restric- 
tions, then it will prevent the initialization parameters 
from being passed on to the Enginelnit method of the 
implementation instance, thereby, preventing the imple- 
mentation instance, and hence, the Cipher instance 
from initializing. If the Cipher instance is not initialized, 
then it will be incapable of regular operation. Thus, by 
preventing initialization, the Init method effectively 
renders the Cipher instance inoperable. In this manner, 
the Init method acts as enforcement logic for ensuring 
that the encapsulated restrictions are enforced on the 
implementation instance. 

[0043] Where an ExemptionMechanism instance is 
encapsulated within the Cipher instance, the Init method 
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of the Cipher class 306 performs an additional function. 
That function is to make sure that the ExemptionMech- 
anism instance has been properly invoked by the appli- 
cation 104 to perform whatever operations are neces- 
sary prior to carrying out any data encryption. For ex- 
ample, where the exemption mechanism is key recov- 
ery, the ExernptionMechanism instance needs to be in- 
voked to generate and to store key recovery blocks be- 
fore any data encryption can be performed. To ensure 
that the necessary operations have been performed by 
the ExernptionMechanism instance, the Init method 
calls the IsCryptoAllowed method of the Exernption- 
Mechanism instance. In one embodiment, the Exernp- 
tionMechanism instance maintains within itself an indi- 
cation as to whether its GenExemptionBlob method has 
been invoked (it is this method that causes the neces- 
sary exemption mechanism operations to be per- 
formed). This indication can be accessed by calling the 
IsCryptoAllowed method. If this method indicates that 
the necessary operations have been performed (i.e. that 
the GenExemptionBlob method has been invoked), 
then the Init method will allow the implementation in- 
stance, and hence, the Cipher instance to initialize. Oth- 
erwise, the Init method will prevent initialization, thereby 
rendering the Cipher instance inoperable. Thus, not only 
does the Init method enforce the restrictions on the im- 
plementation instance, it also ensures that the exemp- 
tion mechanism is enforced. 

[0044] As mentioned above, it is the GetCryptoPer- 
mission method of the JCESecurityManager class 316 
that determines the restrictions to be imposed on the 
services provided by the Cipher instance. These restric- 
tions are determined based upon the specified limita- 
tions 1 08 and the permissions 1 1 0, if any, granted to the 
calling application 104. One embodiment of the Get- 
CryptoPermission method will be disclosed below, but 
before the embodiment is described in detail, a short dis- 
cussion of the limitations 108 and the permissions 110 
will be provided in order to facilitate a complete under- 
standing of the invention. 

[0045] In one embodiment, the limitations 108 com- 
prises two sets of limitations, a default set and an ex- 
empt set. Basically, the default set specifies the default 
limitations that are to be imposed on encryption algo- 
rithms when no exemption mechanisms are implement- 
ed, and the exempt set specifies limitations that are to 
be imposed when certain exemption mechanisms are 
implemented. In general, if an exemption mechanism is 
implemented, stronger cryptographic parameters may 
be used. In one embodiment, both sets of limitations are 
based upon applicable laws and regulations. 
[0046] Each set (default or exempt) of limitations com- 
prises zero or more entries. Each entry specifies a par- 
ticular encryption algorithm, and some limitation(s) to be 
imposed on that algorithm. The format of the entries in 
each set of limitations may be the same. In one embod- 
iment, each entry comprises fields or information con- 
tainers for storing the following information: (1) an en- 



cryption algorithm name or identifier; (2) an exemption 
mechanism name or identifier; (3) a maximum key size; 
and (4) other algorithm-specific encryption limitations, 
such as the maximum number of encryption rounds that 

5 can be performed. For purposes of the present inven- 
tion, the entries may take on any desired form. For ex- 
ample, each entry may be implemented as an object 
having the necessary information encapsulated therein , 
or each entry may be a set of text within a file. So long 

10 as the proper information is provided, any desired form 
may be used. 

[0047] With reference to Fig. 5, there is shown a sam- 
ple of a default set and an exempt set of limitations. No- 
tice that none of the entries in the default set specifies 

'5 an exemption mechanism, while all of the entries in the 
exempt set do. This is as it should be since the default 
set specifies limitations to be imposed when no exemp- 
tion mechanisms are implemented, and the exempt set 
specifies limitations to be imposed when certain exemp- 

20 tion mechanisms are implemented. 

[0048] Interpretation of the default set of limitations is 
straightforward. Basically, each entry sets forth the max- 
imum encryption parameters for a particular encryption 
algorithm. Thus, according to Fig. 5, for the Biowfish al- 

25 gorithm, a maximum key size of 128 bits can be used. 
Similarly, for the RC5 algorithm, a maximum key size of 
64 bits and a maximum number of encryption rounds of 
10 can be used. Interpretation of the exempt set is al- 
most as straightforward. Basically, the first entry of the 

30 exempt set indicates that if the key recovery exemption 
mechanism is implemented in conjunction with the 
Biowfish algorithm, then an increased maximum key 
size of 256 bits can be used. Similarly, the second entry 
indicates that if the key escrow exemption mechanism 

35 js implemented in conjunction with the Biowfish algo- 
rithm, then an increased maximum key size of 256 bits 
can be used. Notice that the same algorithm name 
(Biowfish in this case) can appear in more than one entry 
in the exempt set. So long as the exemption mecha- 

40 nisms specified in these entries are different, this is per- 
missible. 

[0049] The specified limitations 108 are just some of 
the factors taken into account in determining the restric- 
tions imposed on the Cipher instance. Another factor is 

45 the permissions 1 1 0, if any, granted to the calling appli- 
cation 104. As mentioned previously, some types of ap- 
plications, such as health care and banking applica- 
tions, are allowed to use stronger cryptography than oth- 
ers. For these and other applications, the privilege of 

50 using stronger cryptography is reflected in the permis- 
sions 110 granted to the applications. In one embodi- 
ment, the permissions 110 take one of several forms. 
The first form is a CryptoAII Permission indication. When 
an application is given CryptoAIIPermission, it implies 

55 that the application has all possible permissions. In a 
sense, the application is unrestricted. This is the highest 
possible permission that can be granted, and as such, 
it is granted to very few applications. 
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[0050] A lesser permission that can be granted to an 
application is a permission to implement a particular en- 
cryption algorithm with increased or even unlimited 
cryptographic strength. In one embodiment, this type of 
permission specifies a particular algorithm name (e.g. 
Blowfish) and optionally a set of maximum parameters 
(e.g. a maximum key size). If a set of maximum param- 
eters is specified, then the encryption algorithm may be 
implemented up to the level of the specified maximum 
parameters. If a set of maximum parameters is not spec- 
ified, then the encryption algorithm may be implemented 
at any level (i.e. the algorithm is unrestricted). Thus, if 
the permission specifies Blowfish with a max key size 
of 128 bits, then the application is able to use the Blow- 
fish encryption algorithm with a max key size of 1 28 bits. 
If the permission simply specifies Blowfish, then the ap- 
plication is able to use the Blowfish encryption algorithm 
with an unlimited key size. Thus far, the maximum pa- 
rameters have been discussed only in terms of a max 
key size. It should be noted that the maximum parame- 
ters may include other parameters, such as the maxi- 
mum number of encryption rounds. Such other param- 
eters may be required by certain encryption algorithms, 
such as RC5, and thus may be included with the maxi- 
mum parameters. 

[0051] Yet another permission that can be granted to 
an application is a permission to implement a particular 
exemption mechanism in conjunction with a particular 
encryption algorithm (e.g. key recovery with Blowfish). 
As mentioned previously, implementing an exemption 
mechanism usually enables an application to use 
stronger encryption parameters (e.g. larger key sizes). 
Thus, the permission to implement an exemption mech- 
anism can lead to significantly enhanced cryptographic 
strength. Whether it actually does or not depends upon 
the contents of the limitations 108, and whether an im- 
plementation for the exemption mechanism is available, 
as will be discussed below. At this point, it should be 
noted that an application may be granted more than one 
permission. For example, it may be allowed to imple- 
ment more than one type of exemption mechanism. In 
that and other cases, a single application may have 
more than one permission granted to it. 
[0052] With this background information in mind, and 
with reference to the flow diagram of Fig. 6, the opera- 
tion of the GetCryptoPermission method of the JCESe- 
curityManager class 316 will now be described. When 
the GetCryptoPermission method is called, it gets 
passed to it a set of parameters including the name of 
the encryption algorithm (e.g. Blowfish) being requested 
by the calling application 104. In response to the call, 
the GetCryptoPermission method first determines ( 604 ) 
which application 104 is the calling application. That is, 
the GetCryptoPermission method determines which ap- 
plication 1 04 called the Getlnstance method that caused 
the GetCryptoPermission method to be called. In one 
embodiment, the GetCryptoPermission method makes 
this determination by traversing the call stack. This in- 



volves tracing the call sequence from the GetCryptoPer- 
mission method back to the Getlmpl method back to the 
Getlnstance method back to the application 104 which 
made the original Getlnstance method call. By travers- 
5 ing the call stack in this manner, the GetCryptoPermis- 
sion method is able to determine the original calling ap- 
plication 104. 

[0053] Once the calling application 1 04 is determined, 
a determination ( 608 ) is made as to whether the calling 

io application 104 has any valid permissions granted 
thereto. In one embodiment, this is done by first deter- 
mining whether any permissions have been granted to 
the application 104 at all. in one embodiment, this de- 
termination is made by checking the files associated 

*5 with the application 1 04 to see whether any permissions 
have been included therein. In a Java programming en- 
vironment, the files of an application are contained in a 
JAR file, and in such an environment, it is this JAR file 
that is checked for permissions. 

20 [0054] If any permissions are found, then a verifica- 
tion process is carried out to ensure that the permissions 
are valid. In one embodiment, this verification is per- 
formed using digital signatures. More specifically, any 
application 104 that contains one or more permissions 

25 has its JAR file digitally signed. This digital signature 
provides assurance that the application 104 is from a 
trusted source, and that its contents have not been al- 
tered. If this digital signature is verified, then it means 
that the permissions contained within the JAR file are 

30 valid. Otherwise, the permissions are invalid. The Get- 
CryptoPermission method uses a digital signature veri- 
fication mechanism to perform this verification. For pur- 
poses of the present invention, any effective digital sig- 
nature verification mechanism may be used. 

35 [0055] If the GetCryptoPermission method deter- 
mines that the calling application 104 has no valid per- 
missions, then the GetCryptoPermission method deter- 
mines ( 612 ) the restrictions to be imposed on the Cipher 
instance based upon the limitations in the default set of 

40 limitations. More specifically, the GetCryptoPermission 
method searches through the entries in the default set 
for an entry having the same algorithm name as the en- 
cryption algorithm being requested by the calling appli- 
cation 104. Once that entry is found, the restrictions are 

45 derived from the limitations (e.g. max key size and other 
limitations) specified in that entry. For example, if the 
calling application 104 is requesting an implementation 
for the Blowfish algorithm, then according to the sample 
in Fig. 5, the restrictions would be: Blowfish with max 

so key size of 128 bits. Once the restrictions are deter- 
mined, they are returned ( 616 ) by the GetCryptoPermis- 
sion method to the Getlmpl method of the JCESecurity 
class 314. 

[0056] Returning to ( 608 ), if the GetCryptoPermission 
55 method determines that the calling application 1 04 does 
have one or more valid permissions, then the GetCryp- 
toPermission method determines ( 620 ) whether any of 
those permissions is a Cry ptoAII Permission. If so, then 
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the application 104 is unrestricted, in which case, the 
GetCryptoPermission method returns (624 ) an indica- 
tion of no restrictions to the Getlmpl method. However, 
if none of the permissions is a CryptoAIIPermission, then 
the GetCryptoPermission method proceeds to ( 628 ). 5 
[0057] By the time ( 628 ) is reached, it is known that 
the application 104 has one or more valid permissions 
and that none of those permissions is a CryptoAIIPer- 
mission. Thus, it means that the permissions are of one 
of two types: (1) the type that does not require an ex- to 
emption mechanism to be enforced (i.e. the type that 
specifies a particular encryption algorithm and optional- 
ly a set of maximum parameters); or (2) the type that 
does require an exemption mechanism to be enforced 
(i.e. the type that specifies a particular exemption mech- is 
anism in conjunction with a certain encryption algo- 
rithm). At ( 628 ), the GetCryptoPermission method de- 
termines whether any of the permissions is of the type 
that does not require an exemption mechanism to be 
enforced. If any of the permissions are of this type, then 20 
for each of those permissions, a determination ( 632 ) is 
made as to whether that permission can be applied. A 
permission can be applied if the encryption algorithm 
specified in the permission is the same as the encryption 
algorithm being requested by the application 104. For 25 
example, if the application 104 is requesting an imple- 
mentation for the Blowfish algorithm, then a permission 
applies if it specifies the Blowfish algorithm. In one em- 
bodiment, at most one permission can be applied. If the 
GetCryptoPermission method determines that one of 30 
the permissions applies, then the GetCryptoPermission 
method determines the restrictions to be imposed on the 
Cipher instance based upon the maximum parameters 
(if any) specified in the permission. That is, if a set of 
maximum parameters is specified in the permission, 35 
then the restrictions are determined based upon the 
specified maximum parameters. If a set of maximum pa- 
rameters is not specified, then the restrictions are de- 
termined to be unlimited, in which case the encryption 
algorithm is unrestricted. Once the restrictions are de- 40 
termined, they are returned ( 636 ) by the GetCryptoPer- 
mission method to the Getlmpl method of the JCESe- 
curity class 314. 

[0058] Returning to (632 ), if the GetCryptoPermission 
method determines that it cannot apply any of the per- « 
missions that do not require an exemption mechanism 
to be enforced, then il proceeds to ( 640 ). At ( 640 ), the 
GetCryptoPermission method determines whether any 
of the permissions granted to the application 104 is of 
the type that requires an exemption mechanism to be 50 
enforced. If no such permission is found, then the Get- 
CryptoPermission method uses the default set of limita- 
tions to determine (644 ) the restrictions to be imposed 
on the Cipher instance. The manner of determining the 
restrictions is the same as that described above in con- 55 
nection with (612 ). Once the restrictions are determined, 
they are returned ( 648 ) by the GetCryptoPermission 
method to the Getlmpl method. 



[0059] On the other hand, if the GetCryptoPermission 
method determines that at least one of the permissions 
granted to the application 1 04 is of the type that requires 
an exemption mechanism to be enforced, then it pro- 
ceeds to ( 652 ). At (652), the GetCryptoPermission 
method determines whether any of the permissions that 
requires an exemption mechanism to be enforced can 
be applied. More specifically, the GetCryptoPermission 
method determines which of those permissions apply to 
the encryption algorithm being requested, and for each 
that applies, whether that particular encryption algo- 
rithm/exemption mechanism combination is allowed, 
and whether an implementation for the specified exemp- 
tion mechanism is available. In carrying out these func- 
tions, the GetCryptoPermission method refers to the ex- 
empt set of limitations. These operations are best un- 
derstood with reference to an example. 
[0060] Suppose that the encryption algorithm being 
requested is the Blowfish algorithm, and that the appli- 
cation has been granted two permissions: (1) key weak- 
ening in conjunction with Blowfish; and (2) key recovery 
in conjunction with Blowfish. Suppose further that the 
exempt set of limitations is that shown in Fig. 5. In this 
example, both permissions apply to the algorithm being 
requested since both relate to Blowfish; thus, both per- 
missions will be processed, beginning with the first. The 
first permission allows key weakening to be used in con- 
junction with Blowfish. To determine whether this per- 
mission can be used, the GetCryptoPermission method 
searches through the exempt set for an entry having this 
combination. The exempt set contains two entries for 
Blowfish, but neither of these entries specifies key 
weakening as the exemption mechanism. Thus, be- 
cause the combination of Blowfish with key weakening 
is not explicitly allowed by the exempt set of limitations, 
this permission cannot be used or applied. 
[0061] That being the case, the GetCryptoPermission 
method proceeds to the next permission which permits 
key recovery to be used in conjunction with Blowfish. 
This permission is processed in the same manner as 
the first, namely, by searching through the entries in the 
exempt set. This time, an entry is found which allows 
the specified combination of Blowfish with key recovery. 
As a result, this permission may potentially be used/ap- 
plied. However, the inquiry does not end there. Before 
the GetCryptoPermission method allows the permission 
to be used, the GetCryptoPermission method deter- 
mines whether a valid implementation for the specified 
exemption mechanism (key recovery in this example) is 
available. If not, then the permission cannot be applied. 
In making this determination, the GetCryptoPermission 
method searches for a valid general implementation 1 06 
(Fig. 3) which implements the specified exemption 
mechanism. By the end of this process (652), the Get- 
CryptoPermission method will know whether any of the 
granted permissions can be applied. 
[0062] If the GetCryptoPermission method deter- 
mines that a permission can be applied, then the Get- 
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CryptoPermission method uses the exempt rather than 
the default set of limitations to determine (656 ) the re- 
strictions to be imposed on the Cipher instance. More 
specifically, the GetCryptoPermission method derives 
the restrictions from the entry in the exempt set having 5 
the same algorithm name and exemption mechanism 
as the permission. In the example given, the entry is the 
first entry in the exempt set, and the restrictions are: 
Blowfish with key recovery with a max key size of 256 
bits. Once these restrictions are determined, they are 10 
returned ( 660 ) by the GetCryptoPermission method to 
the Getlmpl method of the JCESecurity class 314. As 
noted above, the entries in the exempt set typically allow 
stronger cryptographic parameters to be used than the 
default set. Thus, by deriving the restrictions from the '5 
exempt set, the GetCryptoPermission method enhanc- 
es the cryptographic strength of the Cipher instance. 
[0063] Returning to ( 652 ), if none of the permissions 
can be applied, then the GetCryptoPermission method 
uses the default set of limitations to determine ( 644 ) the 20 
restrictions to be imposed on the Cipher instance. The 
manner of determining the restrictions is the same as 
that described above in connection with (61 2). Thus, the 
application 104 is treated the same as if it had been 
granted no permissions at all. Once the restrictions are 25 
determined, they are returned ( 648 ) by the GetCryp- 
toPermission method to the Getlmpl method. In the 
manner described, the GetCryptoPermission method 
determines the restrictions to be imposed on the Cipher 
instance. By trying to apply the permissions first, and 30 
then using the default limitations only when none of the 
permissions apply, the GetCryptoPermission method 
tries to grant the Cipher instance the greatest crypto- 
graphic strength possible given the limitations. Put an- 
other way, the GetCryptoPermission method attempts 35 
to impose the lowest level of restrictions possible. 
[0064] It was previously mentioned that the default 
and exempt sets of limitations that comprise the overall 
set of limitations 108 (Fig. 1) are based upon applicable 
laws and regulations. In one embodiment, they are de- *o 
rived based upon at least two sets of laws and regula- 
tions: (1) U. S. export laws; and (2) local laws (the laws 
of the country or locality into which the framework 1 02 
is imported). Because these sets of laws often differ, in 
order to derive a single set of limitations consistent with 45 
both sets of laws, a reconciliation process is performed. 
In one embodiment, this reconciliation process takes the 
form of a merge. More specifically, the two sets of laws 
are merged to produce the resultant set of limitations 
1 08, and the merger is performed in such a way that the so 
resultant limitations 108 comprise the most restrictive 
limitations of the two sets of laws. By selecting the most 
restrictive limitations, the merging process ensures that 
the resultant limitations 108 comply with both sets of 
laws. 55 
[0065] Fig. 7 shows an overview of the merging proc- 
ess. As shown, the U. S. export laws 702 comprise a 
default component 706 and an exempt component 708. 



Likewise, the local laws 704 comprise a default compo- 
nent 710 and an exempt component 712. The default 
components 706, 71 0 specify the default limitations that 
are to be imposed on encryption algorithms when no ex- 
emption mechanisms are implemented, and the exempt 
components 708, 712 specify the limitations that are to 
be imposed when certain exemption mechanisms are 
implemented. In one embodiment, the default 706, 710 
and exempt 708, 712 components have the same for- 
mat as the default 714 and exempt 716 sets of limita- 
tions described previously in connection with Fig. 5. 
That is, each component 706, 710, 708, 712 comprises 
zero or more entries, and each entry comprises a field 
or container for storing: (1) an encryption algorithm 
name or identifier; (2) an exemption mechanism name 
or identifier; (3) a maximum key size; and (4) other en- 
cryption limitations. To derive the resultant limitations 
108, the default components 706, 710 are merged, entry 
by entry, to give rise to the default set 714 of resultant 
limitations 108, and the exempt components 708, 712 
are merged, entry by entry, to give rise to the exempt 
set 716 of resultant limitations 108. Once derived, the 
resultant limitations 108 may be used by the GetCryp- 
toPermission method of the JCESecurityManager class 
316 to determine the restrictions to be imposed on the 
Cipher instance. 

[0066] With reference to the flow diagram of Fig. 8, 
one embodiment of the merging process will now be de- 
scribed. In the following discussion, reference will be 
made to policies A, B and C. Policies A and B refer to 
the information sources of the merge (e.g. the U. S. ex- 
port laws and the local laws) while policy C refers to the 
result of the merge (e.g. the resultant limitations 108). 
As shown in Fig. 7, the default components 706, 710 
and the exempt components 708, 712 are merged sep- 
arately in separate merging operations. However, it 
should be noted the same merging process may be 
used for both merges. 

[0067] Referring now to Fig. 8, the merging process 
begins with selecting ( 804 ) the next entry (in this case, 
the first entry) in policy A. The selected entry is corn- 
pared with the entries in policy B to determine ( 808 ) 
whether there is a corresponding entry in policy B. In 
one embodiment, this determination is made by com- 
paring the algorithm name and the exemption mecha- 
nism name of the selected entry with the algorithm name 
and the exemption mechanism name of the entries in 
policy B. If any entry in policy B has the same combina- 
tion of algorithm name and exemption mechanism 
name, then a corresponding entry is found. In such a 
case, the limitations of the two corresponding entries are 
compared to determine ( 820 ) the most restrictive limita- 
tions. 

[0068] As an example of how this is done, suppose 
that both policies A and B have an entry with RC5 as 
the algorithm name and no named exemption mecha- 
nism. Suppose that the entry in policy A has a max key 
size of 64 bits and a maximum number of rounds of 1 2, 
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while the entry in policy B has a max key size of 128 bits 
and a maximum number of rounds of 1 0. In such a case, 
the most restrictive limitations would be a max key size 
of 64 bits and a maximum number of rounds of 1 0. Thus, 
as this example illustrates, the most restrictive limita- 
tions are determined on a limitation by limitation basis. 
[0069] Once the most restrictive limitations are deter- 
mined, a new entry is created ( 824 ) in policy C. This new 
entry will have the same algorithm name and exemption 
mechanism name as the two corresponding entries. In 
addition, it will have as its limitations the most restrictive 
limitations determined in ( 820 ). Once the new entry is 
created in policy C, processing of the current selected 
entry is complete. Thus, a determination ( 828 ) is made 
as to whether there are any more entries in policy A. If 
so, then the process loops back to ( 804 ) to select and 
process the next entry in policy A. Otherwise, the proc- 
ess proceeds to (832 ). 

[0070] Returning to ( 808 ), if it is determined that there 
is no entry in policy B which corresponds to the selected 
entry in policy A, then a determination (812 ) is made as 
to whether policy B has a wildcard entry. This wildcard 
entry acts as a catchall for all of the algorithm name/ 
exemption mechanism combinations that are not explic- 
itly listed in policy B. If no wildcard entry is found in policy 
B, then processing of the selected entry is complete. No 
new entry will be created in policy C, and the process 
proceeds to ( 828 ) to look for more entries in policy A. 
[0071 ] On the other hand, if it is determined that policy 
B does have a wildcard entry, then the limitations of the 
selected entry are compared with the limitations of the 
wildcard entry to determine (816 ) the most restrictive 
limitations. This determination is made in the same man- 
ner as that described above in connection with (820 ). 
Once the most restrictive limitations are determined, a 
new entry is created (824 ) in policy C. This new entry 
will have the same algorithm name and exemption 
mechanism name as the selected entry. In addition, it 
will have as its limitations the most restrictive limitations 
determined in ( 816 ). Once the new entry is created in 
policy C, processing of the current selected entry is com- 
plete. Thus, a determination ( 828 ) is made as to whether 
there are any more entries in policy A. If so, then the 
process loops back to ( 804 ) to select and process the 
next entry in policy A. This process continues until all of 
the entries In policy A have been processed. 
[0072] Once all of the entries in policy A have been 
processed, it is time to process all of the entries in policy 
B which did not correspond to entries in policy A. Before 
doing this, however, a determination ( 832 ) is made as 
to whether policy A has a wildcard entry. If policy A does 
not have a wildcard entry, then there is no point in 
processing the additional entries in policy B since these 
entries would not result in additional entries being cre- 
ated in policy C. Thus, if policy A has no wildcard entry, 
the construction of policy C is completed (836 ). 
[0073] On the other hand, if policy A has a wildcard 
entry, then processing of policy B begins with selecting 



( 840 ) the next entry (the first entry in this case) in policy 
B. The selected entry is compared with the entries in 
policy C to determine (844 ) whether there is a corre- 
sponding entry in policy C. In one embodiment, this de- 

5 termination is made by comparing the algorithm name 
and the exemption mechanism name of the selected en- 
try with the algorithm name and the exemption mecha- 
nism name of the entries in policy C. If a corresponding 
entry is found in policy C, then it means that the selected 

'0 entry was already processed as part of the processing 
of the entries of policy A. In such a case, no further 
processing of the selecting entry is needed. As a result, 
the process proceeds to (856 ) to look for more entries 
in policy B. 

is [0074] On the other hand, if the selected entry does 
not correspond to any of the entries in policy C, then the 
limitations of the selected entry are compared with the 
limitations of the wildcard entry of policy A to determine 
( 848 ) the most restrictive limilations. This determination 
is made in the same manner as that described above in 
connection with ( 820 ). Once the most restrictive limita- 
tions are determined, a new entry is created (852 ) in pol- 
icy C. This new entry will have the same algorithm name 
and exemption mechanism name as the selected entry. 
In addition, it will have as its limitations the most restric- 
tive limitations determined in ( 848 ). Once the new entry 
is created in policy C, processing of the current selected 
entry is complete. Thus, a determination ( 856 ) is made 
as to whether there are any more entries in policy B. If 
so, then the process loops back to ( 840 ) to select and 
process the next entry in policy B, This process contin- 
ues until all of the entries in policy B have been proc- 
essed. Once that is done, the construction of policy C is 
completed ( 860 ). 

[0075] In one embodiment, the merging process just 
described is carried out by the initializer of the JCESe- 
curity class 314. This initializer is invoked the very first 
time the JCESecurity class 314 is invoked. When in- 
voked, it merges two or more sets of laws provided to it 
to give rise to an overall set of limitations 1 08. It is this 
overall set of limitations 108 (comprising a default set 
and an exempt set) that is thereafter used by the Get- 
CryptoPermission method to determine the restrictions 
to be imposed on a Cipher instance. 
[0076] It was previously mentioned that it is the Getlm- 
pl method of the JCESecurity class 314 that is respon- 
sible for instantiating an associated general implemen- 
tation 106 to give rise to an implementation instance. As 
part of the instantiation process, the Getlmpl method 
carries out an authentication process. In one embodi- 
ment, this authentication process takes the form of mu- 
tual authentication whereby the Getlmpl method au- 
thenticates the associated general implementation 106, 
and the associated general implementation 106 authen- 
ticates the framework 1 02. In one embodiment, to make 
it possible for this mutual authentication to take place: 
(1) the JAR file of the associated general implementa- 
tion 106 is digitally signed; (2) the JAR file of the frame- 
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work 102 is digitally signed; (3) the JCESecurity class 
314 has embedded within it a set of obfuscated trusted 
public keys which can be used to verify the signature of 
the associated general implementation's JAR file; and 
(4) the associated general implementation 1 06 has em- 
bedded within it a set of trusted public keys which can 
be used to verify the signature of the framework's JAR 
file. 

[0077] Given this foundation, the mutual authentica- 
tion is carried out as follows. First, using the obfuscated 
trusted public keys embedded within the JCESecurity 
class 314, the Getlmpl method verifies the digital signa- 
ture of the associated general implementation's JAR 
file. If this digital signature is verified, then the Getlmpl 
method instantiates the associated general implemen- 
tation 106, causing the constructor of the associated 
general Implementation to be invoked. When invoked, 
the constructor verifies the digital signature of the frame- 
work's JAR file using the trusted public keys embedded 
within the associated general implementation 106. If the 
constructor determines that the digital signature of the 
framework's JAR file is authentic, then it will construct 
the requested implementation instance. Otherwise, it 
will return an error. As this discussion shows, an imple- 
mentation instance will be constructed only if both the 
associated general implementation 106 and the frame- 
work 102 are authenticated. 

[0078] In carrying out this authentication process, the 
Getlmpl method relies upon an external digital signature 
verification mechanism. That is, in one embodiment, the 
Getlmpl method does not perform the signature verifi- 
cation itself. Rather, it submits the digital signature of 
the associated general implementation 1 06 and the ob- 
fuscated trusted public keys to an external digital signa- 
ture verification mechanism for verification. In one em- 
bodiment, the external digital signature verification 
mechanism is the Signature Mechanism of the Java 
Runtime. While this Signature Mechanism is part of the 
overall Java environment, it is not a part of the frame- 
work 1 02. Thus, from the point of view of the framework 
1 02, it is not a "trusted" component. As a result, before 
it can be relied upon to provide accurate and reliable 
results, the Signature Mechanism itself is verified to en- 
sure that it is legitimate (i.e. that it is performing the prop- 
er verification function). 

[0079] To enable it to verify the Signature Mechanism, 
the JCESecurity class 314 has embedded within it at 
least two digital signatures, one that is known to be ver- 
ifiable using the obfuscated trusted public keys, and an- 
other that is known to be unverifiable using the obfus- 
cated trusted public keys. These signatures are submit- 
ted to the Signature Mechanism in an unpredictable se- 
quence to test the legitimacy of the Mechanism. One 
possible embodiment of the process for testing the Sig- 
nature Mechanism is shown in Fig. 9. 
[0080] As shown, the verification process begins with 
determining ( 904 ) which digital signature (the verifiable 
one or the unverifiable one) to submit to the Signature 



Mechanism. This determination is made in a manner 
that is unpredictable to the Signature Mechanism, and 
in one embodiment, is made using a random process. 
For example, a random number is generated, and if the 

5 random number is within a certain range (e.g. is equal 
to 0), then one of the signatures will be selected, and if 
the random number is within another range (e.g. is equal 
to 1), then the other signature will be selected. In one 
embodiment, the determination (904) also takes into ac- 

10 count which signatures were previously selected. If ail 
previous selections were of the same signature, then 
( 904 ) causes the other signature to be selected. This 
ensures that each of the two signatures is selected at 
least once to fully test the legitimacy of the Signature 
Mechanism. 

[0081 ] Once one of the signatures has been selected, 
the selected signature and the obfuscated trusted public 
keys are submitted ( 908 ) to the Signature Mechanism 
for verification. In turn, the Signature Mechanism pro- 

20 vides a response indicating either that the signature was 
verified or that the signature was not verified. This re- 
sponse is received ( 912 ) and checked ( 916 ) for accura- 
cy. More specifically, if the signature submitted to the 
Signature Mechanism was the verifiable one, the re- 

25 sponse is checked for an indication that the signature 
was verified. If the signature submitted to the Signature 
Mechanism was the unverifiable one, the response is 
checked for an indication that the signature was unver- 
ified. If the response received is not correct for the sig- 

30 nature that was submitted, then it is determined ( 920 ) 
that the Signature Mechanism is not legitimate. In such 
a case, the verification process is terminated ( 924 ). 
[0082] On the other hand, if the response received is 
correct for the signature submitted, then a determination 

55 ( 928 ) is made as to whether the verification process has 
been performed an n number of times, where n is any 
desired number (e.g. 5). If not, then the process loops 
back to (904 ) to once again submit a signature to the 
Signature Mechanism and to test the response. If the 

^0 process has been performed an n number of times, then 
the process proceeds to ( 932 ). By the time ( 932 ) is 
reached, it is known that the Signature Mechanism has 
provided a correct response to each and every submit- 
ted signature (otherwise, the process would have termi- 

^5 nated at ( 924 ) before reaching (932)). Thus, it is deter- 
mined ( 932 ) that the Signature Mechanism is legitimate. 
In such a case, the Signature Mechanism may be relied 
upon by the Getlmpl method to authenticate the asso- 
ciated general implementation 106. Once the Signature 

so mechanism is verified to be legitimate, the verification 
process is terminated (936 ). 

[0083] The result of the above process is that the ver- 
ifiable and unverifiable digital signatures are submitted 
to the Signature Mechanism in an unpredictable se- 
55 quence. By making the submission sequence unpredict- 
able, the verification process makes it highly difficult if 
not impossible for an illegitimate Signature Mechanism 
to "fake" proper responses. Therefore, this verification 



13 



BNSDCCID: <EP 1 1021$4A2.I_> 



23 



EP1 102 154 A2 



24 



process provides an effective means for testing the le- 
gitimacy of the external Signature Mechanism. 
[0084] Thus far, the verification process has been de- 
scribed with reference to a digital signature verification 
mechanism, it should be noted, however, that the proc- 5 
ess is not so limited. Rather, it may be applied generally 
to test the legitimacy of any untrusted mechanism. So 
long as there are at least two different sets of information 
the correct responses for which are known, the process 
may be applied to test the legitimacy of the untrusted 10 
mechanism. To illustrate how the verification process 
may be applied generally to any untrusted mechanism, 
reference will be made to the flow diagram of Fig. 10. 
[0085] As shown, the verification process begins with 
determining ( 1004 ) which of at least two sets of infor- '5 
mation to submit to the untrusted mechanism. This de- 
termination ( 1004 ) is made in a manner that is unpre- 
dictable to the untrusted mechanism, and in one embod- 
iment, is made using a random process. For example, 
a random number is generated, and if the random 20 
number is within a certain range (e.g. is equal to 0), then 
a first set of information will be selected, and if the ran- 
dom number is within another range (e.g. is equal to 1 ), 
then another set of information will be selected. In one 
embodiment, the determination ( 1004 ) also takes into 25 
account which sets of information were previously se- 
lected. If all previous selections were of the same infor- 
mation set, then ( 1004 ) causes the other information set 
to be selected. This ensures that each of the two infor- 
mation sets is selected at least once to fully test the le- 30 
gitimacy of the untrusted mechanism. 
[0086] Once one of the information sets has been se- 
lected, the selected information set is submitted ( 1008 ) 
to the untrusted mechanism. In turn, the untrusted 
mechanism provides a response to the submitted infor- 35 
mation set. This response is received ( 1012 ) and 
checked ( 1016 ) for accuracy. More specifically, the 
proper response to each information set is known. If the 
response received is not the correct response for the 
information set submitted, then it is determined ( 1020 ) *o 
that the untrusted mechanism is not legitimate. In such 
a case, the verification process is terminated ( 1024 ). 
[0087] On the other hand, if the response received is 
the correct response for the information set submitted, 
then a determination ( 1028 ) Is made as to whether the 45 
verification process has been performed an n number 
of times, where n is any desired number (e.g. 5). If not, 
then the process loops back to ( 1004 ) to once again sub- 
mit an information set to the untrusted mechanism and 
to test the response. If the process has been performed so 
an n number of times, then the process proceeds to 
( 1032 ). By the time ( 1032 ) is reached, it is known that 
the untrusted mechanism has provided a correct re- 
sponse to each and every submitted information set 
(otherwise, the process would have terminated at 55 
( 1024 ) before reaching ( 1032 )). Thus, it is determined 
( 1032 ) that the untrusted mechanism is legitimate. Once 
the untrusted mechanism is verified to be legitimate, the 



verification process is terminated ( 1036 ). 
[0088] The result of the above process is that the two 
information sets are submitted to the untrusted mecha- 
nism in an unpredictable sequence. By making the sub- 
mission sequence unpredictable, the verification proc- 
ess makes it highly difficult if not impossible for an ille- 
gitimate untrusted mechanism to "fake" proper respons- 
es. Therefore, this verification process provides an ef- 
fective means for testing the legitimacy of any untrusted 
mechanism. 

Hardware Overview 

[0089] In one embodiment, the present invention is 
implemented as a set of instructions executable by one 
or more processors. The invention may be implemented 
as part of an object oriented programming system, in- 
cluding but not limited to the Java™ programming sys- 
tem manufactured by Sun Microsystems, Inc. of Moun- 
tain View, California. Fig. 11 shows a hardware block 
diagram of a computer system 1 1 00 in which an embod- 
iment of the invention may be implemented. Computer 
system 1100 includes a bus 1102 or other communica- 
tion mechanism for communicating information, and a 
processor 1104 coupled with bus 1102 for processing 
information. Computer system 1100 also includes a 
main memory 1106, such as a random access memory 
(RAM) or other dynamic storage device, coupled to bus 
1102 for storing information and instructions to be exe- 
cuted by processor 1104. Main memory 1106 may also 
be further used to store temporary variables or other in- 
termediate information during execution of instructions 
by processor 1104. Computer system 1100 further in- 
cludes a read only memory (ROM) 1108 or other static 
storage device coupled to bus 1 1 02 for storing static in- 
formation and instructions for processor 1 1 04. A storage 
device 1110, such as a magnetic disk or optical disk, is 
provided and coupled to bus 1 1 02 for storing information 
and instructions. 

[0090] Computer system 1100 may be coupled via 
bus 1102 to a display 1112, such as a cathode ray tube 
(CRT), for displaying information to a computer user. An 
input device 1114, including alphanumeric and other 
keys, is coupled to bus 1102 for communicating infor- 
mation and command selections to processor 1 1 04. An- 
other type of user Input device is cursor control 1116, 
such as a mouse, a trackball, or cursor direction keys 
for communicating direction information and command 
selections to processor 1104 and for controlling cursor 
movement on display 1112. This input device typically 
has two degrees of freedom in two axes, a first axis (e. 
g., x) and a second axis (e.g., y), that allows the device 
to specify positions in a plane. 

[0091] According to one embodiment, the functional- 
ity of the present invention is provided by computer sys- 
tem 1100 in response to processor 1104 executing one 
or more sequences of one or more instructions con- 
tained in main memory 1106. Such instructions may be 
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read into main memory 1106 from another computer- 
readable medium, such as storage device 1110. Execu- 
tion of the sequences of instructions contained in main 
memory 1106 causes processor 1104 to perform the 
process steps described herein. In alternative embodi- 5 
ments, hard-wired circuitry may be used in place of or 
in combination with software instructions to implement 
the invention. Thus, embodiments of the invention are 
not limited to any specific combination of hardware cir- 
cuitry and software. 10 
[0092] The terms "computer-readable medium" and 
"carrier medium" as used herein refer to any medium 
that participates in providing instructions to processor 
1104 for execution. Such a medium may take many 
forms, including but not limited to, non-volatile media, '5 
volatile media, and transmission media. Non-volatile 
media includes, for example, optical or magnetic disks, 
such as storage device 1110. Volatile media includes dy- 
namic memory, such as main memory 1106. Transmis- 
sion media includes coaxial cables, copper wire and fib- 20 
er optics, including the wires that comprise bus 1102. 
Transmission media can also take the form of acoustic 
or electromagnetic waves, such as those generated dur- 
ing radio-wave, infra-red, and optical data communica- 
tions. 25 
[0093] Common forms of computer-readable media 
include, for example, a floppy disk, a flexible disk, hard 
disk, magnetic tape, or any other magnetic medium, a 
CD-ROM, any other optical medium, punchcards, pap- 
ertape, any other physical medium with patterns of 30 
holes, a RAM, a PROM, and EPROM, a FLASH- 
EPROM, any other memory chip or cartridge, a carrier 
wave as described hereinafter, or any other medium 
from which a computer can read. 

[0094] Various forms of computer readable media 35 
may be involved in carrying one or more sequences of 
one or more instructions to processor 1104 for execu- 
tion. For example, the instructions may initially be car- 
ried on a magnetic disk of a remote computer. The re- 
mote computer can load the instructions into its dynamic *o 
memory and send the instructions over a telephone line 
using a modem. A modem local to computer system 
1 1 00 can receive the data on the telephone line and use 
an infra-red transmitter to convert the data to an infra- 
red signal. An infra-red detector can receive the data *s 
carried in the infra-red signal and appropriate circuitry 
can place the data on bus 1102. Bus 1102 carries the 
data to main memory 1106, from which processor 11 04 
retrieves and executes the instructions. The instructions 
received by main memory 11 06 may optionally be stored so 
on storage device 1110 either before or after execution 
by processor 1104. 

[0095] Computer system 1100 also includes a com- 
munication interface 1118 coupled to bus 1102. Com- 
munication interface 1118 provides a two-way data com- 55 
munication coupling to a network link 1120 that is con- 
nected to a local network 1122. For example, commu- 
nication interface 1118 may be an integrated services 
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digital network (ISDN) card or a modem to provide a da- 
ta communication connection to a corresponding type 
of telephone line. As another example, communication 
interface 1118 may be a local area network (LAN) card 
to provide a data communication connection to a com- 
patible LAN. Wireless links may also be implemented. 
In any such implementation, communication interface 
1118 sends and receives electrical, electromagnetic or 
optical signals that carry digital data streams represent- 
ing various types of information. 
[0096] Network link 1 1 20 typically provides data com- 
munication through one or more networks toother data 
devices. For example, network link 1120 may provide a 
connection through local network 1122 to a host com- 
puter 1 1 24 or to data equipment operated by an Internet 
Service Provider (ISP) 1126. ISP 1126 in turn provides 
data communication services through the world wide 
packet data communication network now commonly re- 
ferred to as the "Internel" 1128. Local network 1122 and 
Internet 11 28 both use electrical electromagnetic or op- 
tical signals that carry digital data streams. The signals 
through the various networks and the signals on network 
link 1120 and through communication interface 1118, 
which carry the digital data to and from computer system 
1 1 00, are exemplary forms of carrier waves transporting 
the information. 

[0097] Computer system 1100 can send messages 
and receive data, including program code, through the 
network(s), network link 1 1 20 and communication inter- 
face 1 1 1 8. 1 n the Internet example, a server 1 1 30 might 
transmit a requested code for an application program 
through Internet 1 1 28, ISP 1 1 26, local network 1 1 22 and 
communication interface 1118. The received code may 
be executed by processor 1104 as it is received, and/or 
stored in storage device 1 1 1 0, or other non-volatile stor- 
age for later execution. In this manner, computer system 
1 1 00 may obtain application code in the form of a carrier 
wave. 

[0098] At this point, it should be noted that although 
the invention has been described with reference to a 
specific embodiment, it should not be construed to be 
so limited. Various modifications may be made by those 
of ordinary skill in the art with the benefit of this disclo- 
sure without departing from the invention. 

Claims 

1. In a system wherein an application requests an im- 
plementation of a particular service, a method for 
determining restrictions to impose on the imple- 
mentation, comprising: 

determining whether any permissions have 
been granted to the application requesting the 
implementation; and 

in response to a determination that at least one 
permission has been granted to the application, 
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processing said permission to derive a set of 
zero or more restrictions to impose on the im- 
plementation. 

2. The method of claim 1 , wherein said permission is 
processed such that said set of restrictions is least 
restrictive. 

3. The method of claim 1 or claim 2, further compris- 
ing: 

in response to a determination that no permis- 
sions have been granted to the application, ac- 
cessing a set of default limitations; and 
deriving said set of zero or more restrictions 
based upon said default limitations. 

4. The method of claim 3, wherein said default limita- 
tions are derived by merging multiple jurisdiction 
policies and extracting therefrom the most restric- 
tive limitations. 

5. The method of any preceding claim, wherein 
processing said permission comprises: 

determining whether said permission is an all- 
encompassing permission; and 
in response to a determination that said permis- 
sion is an all-encompassing permission, pro- 
viding an indication that the implementation is 
unrestricted. 

6. The method of any of claims 1 to 4, wherein 
processing said permission comprises: 

determining whether said permission requires 
an exemption mechanism to be implemented; 
and 

in response to a determination that said permis- 
sion does not require an exemption mechanism 
to be implemented, deriving said set of zero or 
more restrictions based upon said permission. 

7. The method of claim 6, wherein deriving said re- 
strictions comprises: 

determining whether said permission specifies 
a set of parameters; and 
in response to a determination that said permis- 
sion specifies a set of parameters, deriving said 
set of zero or more restrictions based upon said 
parameters. 



8. 



The method of claim 6, wherein deriving said re- 
strictions comprises: 

determining whether said permission specifies 
a set of parameters; and 
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in response to a determination that said permis- 
sion does not specify a set of parameters, pro- 
viding an indication that the implementation is 
unrestricted. 

9. The method of any preceding claim, wherein 
processing said permission comprises: 

determining whether said permission requires 
a particular exemption mechanism to be imple- 
mented; and 

in response to a determination that said permis- 
sion requires a particular exemption mecha- 
nism to be implemented, accessing a set of ex- 
empt limitations; and 

reconciling said permission and said exempt 
limitations to derive said set of zero or more re- 
strictions. 

10. The method of claim 9, wherein reconciling said 
permission and said exempt limitations comprises: 

determining whether said exempt limitations al- 
low said particular exemption mechanism to be 
implemented with the implementation; and 
in response to a determination that said exempt 
limitations allow said particular exemption 
mechanism to be implemented with the imple- 
mentation, deriving said set of zero or more re- 
strictions based upon said exempt limitations. 

11. The method of claim 9, wherein reconciling said 
permission and said exempt limitations comprises: 

determining whether said exempt limitations al- 
low said particular exemption mechanism to be 
implemented with the implementation; 
in response to a determination that said exempt 
limitations do not allow said particular exemp- 
tion mechanism to be implemented with the im- 
plementation, accessing a set of default limita- 
tions; and 

deriving said set of zero or more restrictions 
based upon said default limitations. 

12. The method of any of claims 9 to 11 . wherein said 
exempt limitations are derived by merging multiple 
jurisdiction policies and extracting therefrom the 
most restrictive limitations. 



50 



13. The method of any preceding claim, wherein deter- 
mining whetherany permissions have been granted 
to the application comprises: 

traversing a call stack to determine which ap- 
55 plication requested the implementation. 

14. The method of claim 13, wherein determining 
whether any permissions have been granted to the 
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application further comprises: 

authenticating the application. 

15. In a system wherein an application requests an im- 
plementation of a particular service, a mechanism 
for determining restrictions to impose on an the im- 
plementation of a particular service requested by an 
application in a computer system, the mechanism 
for determining restrictions comprising: 

a mechanism for determining whether any per- 
missions have been granted to the application 
requesting the implementation; and 
a mechanism for processing, in response to a 
determination that at least one permission has 
been granted to the application, said permis- 
sion to derive a set of zero or more restrictions 
to impose on the implementation. 

1 6. The mechanism for determining restrictions of claim 
15, wherein said permission is processed such that 
said set of restrictions is least restrictive. 

17. The mechanism for determining restrictions of claim 
15 or claim 16, further comprising: 

a mechanism for accessing, in response to a 
determination that no permissions have been 
granted to the application, a set of default limi- 
tations; and 

a mechanism for deriving said set of zero or 
more restrictions based upon said default limi- 
tations. 

18. The mechanism for determining restrictions of claim 
17, wherein said default limitations are derived by 
merging multiple jurisdiction policies and extracting 
therefrom the most restrictive limitations. 

19. The mechanism for determining restrictions of any 
of claims 15 to 18, wherein the mechanism for 
processing said permission comprises: 
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a mechanism for deriving, in response to a de- 
termination that said permission does not re- 
quire an exemption mechanism to be imple- 
mented, said set of zero or more restrictions 
based upon said permission. 

21 . The mechanism for determining restrictions of claim 
20, wherein the mechanism for deriving said restric- 
tions comprises: 

a mechanism for determining whether said per- 
mission specifies a set of parameters; and 
a mechanism for deriving, in response to a de- 
termination that said permission specifies a set 
of parameters, said set of zero or more restric- 
tions based upon said parameters. 



22. The mechanism for determining restrictions of claim 
20, wherein the mechanism for deriving said restric- 
20 tions comprises: 



a mechanism for determining whether said per- 
mission specifies a set of parameters; and 
a mechanism for providing, in response to a de- 
termination that said permission does not spec- 
ify a set of parameters, an indication that the 
implementation is unrestricted. 
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23. The mechanism for determining restrictions of any 
of claims 15 to 22, wherein the mechanism for 
processing said permission comprises: 



a mechanism for determining whether said per- 
mission requires a particular exemption mech- 
anism to be implemented; and 
a mechanism for accessing, in response to a 
determination that said permission requires a 
particular exemption mechanism to be imple- 
mented, a set of exempt limitations; and 
a mechanism for reconciling said permission 
and said exempt limitations to derive said set 
of zero or more restrictions. 



a mechanism for determining whether said per- 
mission is an all-encompassing permission; 
and 

a mechanism for providing, in response to a de- 
termination that said permission is an all-en- 
compassing permission, an indication that the 
implementation is unrestricted. 

20. The mechanism for determining restrictions of any 
of claims 15 to 18, wherein the mechanism for 
processing said permission comprises: 

a mechanism for determining whether said per- 
mission requires an exemption mechanism to 
be implemented; and 



24. The mechanism for determining restrictions of claim 
23, wherein the mechanism for reconciling said per- 
mission and said exempt limitations comprises: 

a mechanism for determining whether said ex- 
empt limitations allow said particular exemption 
mechanism to be implemented with the imple- 
mentation; and 

a mechanism for deriving, in response to a de- 
termination that said exempt limitations allow 
said particular exemption mechanism to be im- 
plemented with the implementation, said set of 
zero or more restrictions based upon said ex- 
empt limitations. 
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25. The mechanism for determining restrictions of claim 
23, wherein the mechanism for reconciling said per- 
mission and said exempt limitations comprises: 

a mechanism for determining whether said ex- 5 
empt limitations allow said particular exemption 
mechanism to be implemented with the imple- 
mentation; 

a mechanism for accessing, in response to a 
determination that said exempt limitations do 10 
not allow said particular exemption mechanism 
to be implemented with the implementation, a 
set of default limitations; and 
a mechanism for deriving said set of zero or 
more restrictions based upon said default limi- '5 
tations. 

26. The mechanism for determining restrictions of any 
of claims 23 to 25, wherein said exempt limitations 

are derived by merging multiple jurisdiction policies 20 
and extracting therefrom the most restrictive limita- 
tions. 

27. The mechanism for determining restrictions of any 

of claims 1 5 to 26, wherein the mechanism for de- 25 
termining whether any permissions have been 
granted to the application comprises: 

a mechanism for traversing a call stack to de- 
termine which application requested the implemen- 
tation. 30 



strictions is least restrictive. 

31 . The computer program of claim 29 or claim 30, fur- 
ther comprising: 

instructions for causing one or more processors 
to access, in response to a determination that 
no permissions have been granted to the appli- 
cation, a set of default limitations; and 
instructions for causing one ormore processors 
to derive said set of zero or more restrictions 
based upon said default limitations. 

32. The computer program of claim 31 , wherein said de- 
fault limitations are derived by merging multiple ju- 
risdiction policies and extracting therefrom the most 
restrictive limitations. 

33. The computer program of any of claims 29 to 32, 
wherein the instructions for causing one or more 
processors to process said permission comprises: 

instructions for causing one ormore processors 
to determine whether said permission is an all- 
encompassing permission; and 
instructions for causing one ormore processors 
to provide, in response to a determination that 
said permission is an all-encompassing per- 
mission, an indication that the implementation 
is unrestricted. 



28. The mechanism for determining restrictions of claim 
27, wherein the mechanism for determining wheth- 
er any permissions have been granted to the appli- 
cation further comprises: 35 

a mechanism for authenticating the applica- 
tion. 

29. A computer program operable, when executed by 
one or more processors, to cause the one or more *o 
processors to determine restrictions to impose on 

an implementation of a particular service requested 
by an application, said computer readable medium 
comprising: 

45 

instructions for causing one or more processors 
to determine whether any permissions have 
been granted to the application requesting the 
implementation; and 

instructions for causing one or more processors so 
to process, in response to a determination that 
at least one permission has been granted to the 
application, said permission to derive a set of 
zero or more restrictions to impose on the im- 
plementation. 55 

30. The computer program of claim 29, wherein said 
permission is processed such that said set of re- 



34. The computer program of any of claims 29 to 32, 
wherein the instructions for causing one or more 
processors to process said permission comprises: 

instructions for causing one ormore processors 
to determine whether said permission requires 
an exemption mechanism to be implemented; 
and 

instructions for causing one ormore processors 
to derive, in response to a determination that 
said permission does not require an exemption 
mechanism to be implemented, said set of zero 
or more restrictions based upon said permis- 
sion. 

35. The computer program of claim 34, wherein the in- 
structions for causing one or more processors to de- 
rive said restrictions comprises: 

instructions for causing one or more processors 
to determine whether said permission specifies 
a set of parameters; and 
instructions for causing one ormore processors 
to derive, in response to a determination that 
said permission specifies a set of parameters, 
said set of zero or more restrictions based upon 
said parameters. 
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36. The computer program of claim 34, wherein the in- 
structions for causing one or more processors to de- 
rive said restrictions comprises: 

instructions for causing one or more processors 
to determine whether said permission specifies 
a set of parameters; and 
instructions for causing one or more processors 
to provide, in response to a determination that 
said permission does not specify a set of pa- 
rameters, an indication that the implementation 
is unrestricted. 



2 154A2 34 

said exempt limitations do not allow said par- 
ticular exemption mechanism to be implement- 
ed with the implementation, a set of default lim- 
itations; and 

5 instructions for causing one or more processors 

to derive said set of zero or more restrictions 
based upon said default limitations. 

40. The computer program of claim 37, wherein said ex- 
10 empt limitations are derived by merging multiple ju- 
risdiction policies and extracting therefrom the most 
restrictive limitations. 



37. The computer program of any of claims 29 to 36, 
wherein the instructions for causing one or more 15 
processors to process said permission comprises: 

instructions for causing one or more processors 
to determine whether said permission requires 
a particular exemption mechanism to be imple- 20 
mented; and 

instructions for causing one or more processors 
to access, in response to a determination that 
said permission requires a particular exemption 
mechanism to be implemented, a set of exempt 25 
limitations; and 

instructions for causing one or more processors 
to reconcile said permission and said exempt 
limitations to derive said set of ?ero or more re- 
strictions. 30 

38. The computer program of claim 37, wherein the in- 
structions for causing one or more processors to 
reconcile said permission and said exempt limita- 
tions comprises: 35 

instructions for causing one or more processors 
to determine whether said exempt limitations 
allow said particular exemption mechanism to 
be implemented with the implementation; and 40 
instructions for causing one or more processors 
to derive, in response to a determination that 
said exempt limitations allow said particular ex- 
emption mechanism to be implemented with 
the implementation, said set of zero or more re- 
strictions based upon said exempt limitations. 

39. The computer program of claim 37, wherein the in- 
structions for causing one or more processors to 
reconcile said permission and said exempt limita- so 
tions comprises: 

instructions for causing one or more processors 
to determine whether said exempt limitations 
allow said particular exemption mechanism to 55 
be implemented with the implementation; 
instructions for causing one or more processors 
to access, in response to a determination that 



41 . The computer program of any of claims 29 to 31 , 
wherein the instructions for causing one or more 
processors to determine whether any permissions 
have been granted to the application comprises: 

instructions for causing one or more proces- 
sors to traverse a call stack to determine which ap- 
plication requested the implementation. 

42. The computer program of claim 41 , wherein the in- 
structions for causing one or more processors to de- 
termine whether any permissions have been grant- 
ed to the application further comprises: 

instructions for causing one or more proces- 
sors to authenticate the application. 

43. A computer program product comprising the com- 
puter program of any of claims 29 to 42 on a carrier 
medium. 

44. A computer system comprising the mechanism for 
determining restrictions of any of claims 15 to 28. 
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DEFAULT SET 



(1) ALGORITHM NAME: BLOWFISH 

EXEMPTION MECHANISM : 
MAX KEY SIZE : 128 BITS 
OTHER LIMITATION (S) : 

(2) ALGORITHM NAME: DES 

EXEMPTION MECHANISM : 
MAX KEY SIZE: 128 BITS 
OTHER LIMITATION (S) : 

(3) ALGORITHM NAME: RC5 

EXEMPTION MECHANISM : 

MAX KEY SIZE: 64 BITS 

OTHER LIMITATION (S) : 10 ROUNDS 



EXEMPT SET 



(1) ALGORITHM NAME: BLOWFISH 

EXEMPTION MECHANISM : KEY RECOVERY 
MAX KEY SIZE : 256 BITS 
OTHER LIMITATION (S) : 

(2) ALGORITHM NAME: BLOWFISH 
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MAX KEY SIZE : 256 BITS 
OTHER LIMITATION (S) : 
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